1. Prior Art
In “conventional” telephony mode (using the public switched telephone network (PSTN)), telephony operators establish bilateral agreements to extend the global coverage of the telephone service. The level of coverage achieved depends essentially on the number of agreements made. In outline, it can be considered that two categories of telecommunications operator are in existence: local and/or national operators, and global operators. The major global operators make a large number of agreements and can thus reach most existing destinations. Local operators make only a small number of agreements, including only one or two with major operators. Thus, a incumbent national operator in a developing country will make agreements with other national operators and one or two agreements with global operators in order to deliver calls to the rest of the world.
At present, most operators are migrating their PSTN networks to solutions and infrastructures that are based on the IP protocol. To accompany the deployment of VoIP services, the Internet engineering task force (IETF) has undertaken a large amount of standardization work. Several protocols have been specified, amongst which mention can be made of session initiation protocol (SIP), session description protocol (SDP), real-time transfer protocol (RTP), real-time transfer control protocol (RTCP), multimedia gateway control protocol (MGCP), session announcement protocol (SAP), and telephony routing over IP (TRIP, RFC3219). These protocols satisfy different requirements and in particular they incorporate call signaling and control, the exchange and control of media streams, and the exchange of call routing information.
TRIP enables interconnected ITADs to exchange all of the destinations they can reach, thereby serving in particular to facilitate the selection of the gateways that are the most appropriate for delivering IP telephony traffic to the PSTN. The TRIP protocol is implemented by location servers (LS) that propagate TRIP routes containing attributes that serve to describe the routes in question. The use of this particular protocol is independent of the type of signaling protocol deployed for actually setting up calls. The TRIP protocol can be used together with SIP, H.323, or any other signaling protocol. Each LS maintains a local routing database known as the telephony routing information database (TRIB). This routing database is fed with advertisements received from neighboring LSes (from another telephony domain, for example). The operation of the TRIP protocol is similar to that of the BGP protocol. Advertisements between neighboring LSes are made in the form of route update messages, referred to simply as update messages. These messages are defined by the TRIP protocol and they are exchanged between LSes in order to inform a neighboring domain about routes that are available.
Activation of the TRIP protocol between various ITADs is described with reference to FIG. 1 (for reasons of simplicity, the term “domain” is also used to denote an ITAD), each ITAD being administered by a single IP telephony operator. Each of these operators has one or more LSes. Each LS maintains a routing database that it feeds with advertisements received from its neighbors (i.e. in other domains) and from LSes in its own domain. These advertisements are updated and forwarded to other neighbors when interconnection agreements permit this.
Thus, the LS of ITAD4 14, for example, updates the advertisements received from the LS of ITAD5 15 and reprogates them to ITAD3 13. It should be observed that an ITAD is not necessarily deployed on a single AS or “IP transfer domain”.
From the routing point of view, an LS handles three types of route:                external routes, received from LSes situated in neighboring ITADs;        internal routes, received from LSes situated in the same ITAD; and        local routes, configured locally in each LS for injection into TRIP processes.This operation is performed either by static configuration or by redistributing information coming from other routing protocols.        
These routes are managed in the routing tables of the telephony routing information base (TRIB). Thus, four types of TRIB are managed by an LS, as is shown in FIG. 2. These tables exist in a single LS, and the relationship between the tables are described with reference to FIG. 2.                “Adj-TRIBs-In” 22: stores routing information conveyed by update messages. This routing information, also referred to as “routes”, constitutes the input to a route selection process 21 (decision process). A given LS maintains an adjacent TRIB-In table 22 for each neighboring LS in which it stores all of the route advertisements received from an adjacent LS;        “Ext-TRIB” 24: only one external TRIB table is maintained by an LS. This table contains the results of a route selection process applied to external routes 25 (Adj-TRIBs-IN) and local routes 26. Prior art techniques enable only one route to be selected per destination;        “Loc-TRIB” 20 (“local TRIB”): this table contains the local routes that result from applying routing policies that are local to each LS; and        “Adj-TRIBs-Out” 23 (adjacent TRIBs out): these are the routes that the local LS will advertise to its peers.        
At IP level, it is possible to use the QoS-enhanced border gateway protocol (q-BGP) in order to be aware of the QoS treatment to which the voice streams will be subjected by the network/transport levels.
2. Drawbacks of the Prior Art
Nevertheless, the inventors have found that, at this stage in the development of the TRIP protocol, no account is taken of correlation with the data transport layer, in particular using the BGP and q-BGP protocols or any other IP routing protocol.
In other words, the service layer, managed by the TRIP protocol, for example, has no information about the state of data transfer at transport layer level, and no information about the ASes that have been passed through in order to place an IP telephony call.
More generally, the present specifications describing the protocols that are implemented for IP data transfer do not correlate the service layer and the network/transport layers.
Thus, at present, an LS has no way of selecting a data transfer path as a function of the IP connectivity operator in charge of routing traffic. The TRIP protocol can maintain the path of ITADs that have been passed through (service layer), but not the path of the ASes that have been passed through (network/transport layers).
In other words, a telephony service operator or provider has no means at present for knowing which ASes voice data transit through, and therefore cannot tell whether they are transmitting through ASes of a competitor, and this applies even when the “service” level path is determined.
Specifically, these drawbacks are illustrated with reference to FIG. 3 showing the dependencies of an IP network both “vertically”, i.e. between ITADs and ASes depending therefrom, and “horizontally”, i.e. between (service) domains and connectivity operators (IP level).
It is assumed that a client S 301 is communicating with a destination client D 302. To do this, the ITAD1 311 from which the client S 301 depends selects the telephone level route passing through ITAD2 312, ITAD3 313, and finally ITAD6 316 from which the destination D 302 depends, in order to cause voice data to be transferred.
Nevertheless, the data itself transits in the IP layer via ASes, from each of which a plurality of ITADs depends. An AS loop or spiral occurs when, at the end of negotiation between ITADs for routing a media stream, this stream passes more than once through a single AS prior to reaching its destination.
In the example shown in FIG. 3, this telephone level route assumes that an IP route exists passing through the domains AS1 321, AS2 322, AS1 321, and finally AS6 326. A spiral is said to exist at IP level. The existence of a spiral can be harmful to the performance of IP datagram transfer since the datagrams pass more than once through AS1.